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Abstract.  A  method  for  verifying  hybrid  systems  is  given.  Such  systems  involve  state 
components  whose  values  are  changed  by  continuous  (physical)  processes.  The  verifi¬ 
cation  method  is  based  on  proving  that  only  those  executions  that  satisfy  constraints 
imposed  by  an  environment  also  satisfy  the  property  of  interest.  A  suitably  expres¬ 
sive  logic  then  allows  the  environment  to  model  state  components  that  are  changed  by 
physical  processes. 

1  Introduction 

What  executions  of  a  concurrent  program  are  possible  and  what  properties  are  satisfied  by  that 
program  may  depend  on  the  environment.  Consider  a  system  to  maintain  a  given  water  level  in 
a  tank.  Under  computer  control,  a  pump  causes  water  to  be  added  and  a  valve  causes  water  to 
be  drained.  Correctness  of  the  control  program  depends  on  the  environment — in  particular,  on 
the  rate  at  which  the  pump  adds  water  and  the  rate  at  which  the  valve  drains  water.  In  fact, 
correctness  of  the  control  program  is  defined  in  terms  of  permissible  states  of  the  environment, 
because  correctness  is  based  on  the  water-level.  One  simply  cannot  specify  or  reason  about  such  a 
control  program  without  saying  something  about  its  environment. 

In  [10]  we  introduced  two  principles  for  verifying  programs  whose  executions  are  affected  by  an 
environment.  The  state  of  the  environments  considered  in  [10]  change  discretely  along  with  each 
atomic  action  of  the  program.  Nevertheless,  our  principles  were  shown  to  be  usable  for  verifying 
real-time  behavior  of  concurrent  programs,  because  schedulers  and  resource  limitations  that  affect 
execution  time  can  be  regarded  as  part  of  the  environment.  In  this  paper,  we  extend  those  results 
to  environments  having  variables  that  change  value  continuously,  as  time  passes.  The  result  is  a 
new  verification  method  for  hybrid  systems. 

The  remainder  of  this  paper  is  structured  as  follows.  In  Section  2,  we  review  the  principles 
introduced  in  [10].  Section  3  presents  a  simple  concurrent  programming  language,  giving  a  plausible 
semantics  for  programs  that  will  control  physical  processes.  Our  specification  language  is  discussed 
in  Section  4.  Section  5  explains  how  invariance-based  proof  methods  for  verifying  safety  properties 

‘Work  supported  in  part  by  the  Office  of  Naval  Research  under  contract  N00014-91-J-1219,  the  National  Science 
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893,  and  AFOSR  grant  F49620-94- 1-0198.  Any  opinions,  findings,  and  conclusions  or  recommendations  expressed  in 
this  publication  are  those  of  the  author  and  do  not  reflect  the  views  of  these  agencies. 
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can  be  used  for  verifying  hybrid  systems  as  well.  Section  6  contains  an  example.  And,  Section  7 
puts  our  work  in  context.  A  soundness  proof  of  our  verification  method  appears  in  an  appendix. 

2  Formalizing  and  Exploiting  the  Environment 

Any  method  for  program  verification  comprises:  a  programming  language,  a  property  language, 
and  a  way  to  prove  that  a  program  P  satisfies  a  property  $.  Program  P  and  the  property  $ 
define  sets  [(P]]  and  {(♦]]  of  behaviors,  where  a  behavior  is  a  mathematical  object  that  describes  an 
execution  of  the  program.  A  program  P  satisfies  a  property  $,  denoted  (P,  $)  €  Sat,  exactly  when 
all  behaviors  of  P  are  permitted  by  $: 

(P,  $)  €  Sat  if  and  only  if  [[P]]  C  [[$]] 

The  environment  in  which  a  program  executes  defines  a  property  too.  This  property  contains 
behaviors  that  are  not  precluded  by  one  or  another  aspect  of  the  environment.  For  example,  with 
the  water  tank  discussed  above,  the  environment  defines  a  property  containing  those  behaviors 
where  the  water  level  changes  continuously  and  only  by  amounts  consistent  with  the  pump’s  rate 
and  the  valve’s  rate.  Behaviors  in  which  the  water  level  changes  abruptly  are  not  in  this  property. 

For  a  property  £  defined  by  an  environment,  the  feasible  behaviors  of  a  program  P  under  £  are 
those  behaviors  of  P  that  are  also  in  £:  [[Pj]  ft  [[£]].  A  program  P  satisfies  a  property  $  under  an 
environment  £,  denoted  (P,£,  $)  €  ESat,  if  and  only  if  every  feasible  behavior  of  P  under  £  is  in 
*: 

(P,£,*)  €  ESat  if  and  only  if  ([[P]]  n  [{£}})  C  [[*]]  (1) 

Based  on  simple  set  theory  and  (1),  we  also  have 

{P,£,*)£ESat  if  and  only  if  [[P]]  C  ([[*]]  U  p]J),  (2) 

where  [[£]]  denotes  the  set  complement  of  [[5]]. 

3  Programs 

Consider  a  simple  programming  language  having  an  empty  statement  (skip),  assignment  (:=), 
sequential  composition  (;),  iteration  (do),  and  parallel  composition  (||).  To  simplify  the  exposition, 
we  assume  that  every  program  is  a  parallel  composition  of  exactly  two  sequential  processes.  The 
syntax  of  a  program  P  is  given  by  the  following  grammar: 

P::  Si\\S2 

S  ::  skip  \x:=e  \  Si;Si  |  do  G\  -*  Si  Q . .  .fl  Gn  — *■  5„  od 

The  skip  statement  does  not  change  any  program  variable;  some  non-zero  time  elapses. 

Assignment  x  :=  e  changes  variable  x  to  be  the  same  value  as  expression  e.  The  value  of  e  is 
computed  at  some  instant  after  execution  of  the  assignment  is  started;  x  is  changed  instantaneously 
after  some  additional  time  elapses.  Thus,  execution  of  our  assignment  involves  performing  two 
atomic  actions. 

Sequential  composition  Si;  S2  is  executed  by  first  executing  S\  and  if  and  when  Si  terminates, 
52  is  executed. 

Execution  of  a  do  statement  5  involves  repeating  the  following  until  no  longer  possible:  use 
guard  evaluation  action  Gvals  to  evaluate  Boolean  guards  G\, . .  .,Gn  and  select  a  corresponding 
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Si  :  do  pa  —  off  A  WL  <  50  -*  pa  :=  on 
0  pa  —  on  A  WI  >95-*  pa  :=  off 
[]  -i(ps  —  off  A  WL  <  50)  A  ->(ps  =  on  A  WL  >  95)  — *  skip 
od 

II 

Sj  :  do  vs  =  c/oae  A  PRESSED  — ►  vs  :=  open 
[]  vs  =  open  A  PRESSED  — ►  vs  :=  dose 
fl  ^PRESSED  -  skip 
od 


Figure  1:  Program  P 

statement  5.  whose  guard  is  true.  Then,  execute  5«.  Thus,  once  none  of  the  guards  evaluates  to 
true,  the  do  terminates.  Execution  of  Goals  is  not  instantaneous  but  uses  values  of  variables  that 
are  all  read  together  some  time  after  Goals  starts;  the  statement  selection  occurs  some  time  after 
these  values  have  been  read. 

Finally,  execution  of  a  parallel  composition  5j  ||  Sj  results  in  the  simultaneous  execution  of  Si 
and  52.  It  terminates  once  both  5i  and  S2  have  terminated. 

Program  Semantics  using  Control-Graphs 

We  represent  a  program  using  a  control  graph — a  collection  of  nodes  and  edges,  not  unlike  a 
flowchart.  Each  node  models  a  delay  prior  to  executing  an  atomic  action;  each  edge  models  exe¬ 
cution  of  an  atomic  action  and  describes  a  state  change  that  occurs  (instantaneously).  Thus,  skip 
gives  rise  to  a  single  node  followed  by  a  single  edge,  whereas  an  assignment  x  :=  e  gives  rise  to  a 
sequence  of  two  nodes — one  whose  outgoing  edge  computes  the  value  of  e  and  a  successor  whose 
outgoing  edge  updates  x. 

Formally,  a  control  graph  is  a  tuple  (V,  E,Vt ntry,  Eexit),  where: 

•  V  is  a  set  of  nodes. 

•  £  is  a  set  of  edges.  Each  edge  (v,  o')  is  labeled  with  a  Boolean  expression  g  and  a  multiple 
assignment  op  (possibly  empty,  i.e.,  skip).  When  convenient,  we  denote  such  a  labeled  edge 
by  the  4-tuple  (v,v\g,op).  We  call  v  the  source  node  of  the  edge  and  call  o'  the  destination 
node.  Destination  node  tf  must  be  either  an  dement  of  V  or  the  distinguished  node 

•  Vm try  is  a  set  of  entry  nodes.  Vestry  C  V. 

•  Peril  is  a  set  of  exit  edges,  those  edges  with  “?”  as  their  destination  node.  £e*i<  Q  E. 

As  an  example,  consider  sequential  subprogram  Si  of  Figure  1.  The  control  graph  of  5i  is  given 
in  Figure  2.  We  use  double  circles  to  indicate  entry  nodes,  and  each  edge  is  labded  with  a  Boolean 
expression  and  an  assignment.1  The  Boolean  expression  labeling  an  edge  must  hold  in  order  for  that 
edge  to  be  traversed;  the  assignment  is  executed  whenever  the  edge  is  traversed.  Thus,  in  Figure 
2,  node  vp  is  the  sole  entry  node  and  allows  the  passage  of  time  before  Gva/5,  reads  variables  ps 
and  WL.  The  edge  from  vo  to  vj,  labded  with  no  guard  and  assignment  ti,ti  :=  ps,  WL,  models 

1  When  the  guard  is  omitted,  ‘true*  is  intended;  when  the  assignment  is  omitted, “skip”  is  intended. 
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that  read.  Edges  from  «i  model  the  actual  selection  (and  exit  from  the  loop).  The  edge  from  vi 
to  ©a  is  labeled  with  Boolean  expression  tj  =  off  A  <  50  to  signify  that  assignment  ps  on  is 
•elected  for  execution  only  if  the  values  read  for  ps  and  WL  satisfy  ps  =  off  A  WL  <  50.  Nodes  v? 
smk*3  model  lseignment  ps  :=  on;  v*  and  vs  model  assignment  ps  :=  off;  and  ®e  models  the  skip. 

Appendix  A  gives  a  procedure  for  translating  a  program  into  a  control  graph.  When  that  proce¬ 
dure  is  used,  the  control  graph  CGp  for  any  program  P:  Si||5j  contains  exactly  two  disconnected 
subgraphs,  each  with  a  single  entry  node:  one  entry  node  is  for  subprogram  Si  and  the  other  is  for 
subprogram  Sj. 

States,  Phases,  and  Traces 

A  state  is  a  mapping  from  variables  to  values.  The  variables  are  partitioned  into  program  variables, 
environment  variables,  control  variables,  and  dock  variables.  Program  variables  (which  are  typeset 
using  lower-case  identifiers)  appear  in  assignments,  as  targets  and/or  expressions.  Execution  is  the 
only  way  to  change  program  variables.  In  the  program  of  Figure  1,  ps  and  vs  are  examples  of 
program  variables. 

Environment  variables  may  appear  in  guards  and  the  expressions  of  assignments  but  may  not 
appear  as  targets  of  assignments.  We  typeset  environment  variables  using  upper-case  identifiers, 
to  distinguish  them  from  program  variables.  Environment  variables  are  presumed  to  be  changed 
by  the  environment,  perhaps  based  on  physical  or  chemical  processes  governed  by  scientific  laws. 
In  Figure  1,  WL  and  PRESSED  are  environment  variables. 

For  verification,  it  is  useful  to  assotiate  with  each  node  v  of  the  control  graph  a  Boolean  control 
variable  v.  The  value  of  control  variable  v  is  true  if  and  only  if  an  atomic  action  modeled  by  an 
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edge  from  node  v  can  next  be  executed.  If  control  variable  v  is  true,  then  we  say  that  node  v  is 
active. 

Finally,  clock  variables  capture  elapsed  time  since  various  control  graph  nodes  were  last  active. 
Clock  variable  now  records  the  elapsed  time  since  the  program  started  execution.  Clock  variable 
tv  contains  the  elapsed  time  since  control  variable  v  last  changed  from  false  to  true  and  has  value 
±  if  v  has  never  become  true.  Thus,  |v  contains  the  elapsed  time  since  node  v  last  became  active. 
And,  dock  variable  jv  contains  the  elapsed  time  since  the  start  of  control  variable’s  v  last  change 
from  true  to  false;  it  has  value  ±  if  v  has  never  been  true. 

Execution  of  a  program  is  modeled  as  a  sequence  of  phases  [18,  12].  Each  phase  gives  values 
to  the  variables  over  some  period  of  time.  We  denote  a  phase  as  a  pair  ([r,r/],/),  where  [r,r'j  is 
a  dosed  interval  of  the  reals  and  /  is  a  mapping  from  [r,r/]  to  states.  Phase  ([r,r/],/)  associates 
state  /(t)  with  any  time  t  such  that  r  <  t  <  r1. 

A  truce  r  is  a  possibly  infinite  sequence  of  phases 

(lri»rl],/i ).  ({**2,  *2],  h) » •  •  •  (3) 

such  that  for  all  t,  rj  =  rj+J.  The  length  |r|  of  a  trace  r  is  defined  to  be  infinity  if  there  are  infinite 
number  of  phases  in  the  trace  and  otherwise  is  rj,  of  its  last  phase  ([rn,  rJJ,  /„).  A  length  m  prefix , 
with  r ,  <  m  <  r[,  of  r,  denoted  by  r..m,  is  a  finite  trace 

(In.  *51.  h),  (fa,  r£],  /a), . . . ,  ([r.,  m],  /,). 

Notice  that  a  trace  associates  two  states  with  the  endpoints  of  each  phase.2  This  is  because  we 
intend  execution  of  an  atomic  action  to  delimit  adjacent  phases.  State  /,(r[)  occurs  just  prior  to 
executing  the  atomic  action  that  terminates  phase  ([rj,  r[],  /<);  state  /,+i(r1+1)  is  the  one  produced 
by  executing  that  atomic  action. 

Trace  r  of  (3)  is  a  behavior  of  a  program  P,  hence  an  dement  of  [[.P]],  provided  all  Btate  changes 
are  consistent  with  execution  of  P.  For  this  to  be  so,  first  we  require  of  initial  phase  ([ri,rj],/i): 

•  rj  =  0. 

•  now  =  0  in  state  /i(ri). 

•  Exactly  the  two  control  variables  that  correspond  to  the  entry  nodes  of  the  control  graph  for 
P  are  true  in  state  /i(ri). 

•  If  a  control  variable  e  is  true  in  state  fifa)  then  clock  variable  tv  equals  0  in  that  state. 
Otherwise  tv  equals  jL  in  state  /i(ri). 

•  For  all  control  variables  v,  |v  equals  JL  in  state  f\(r\). 

Second,  we  require  that  no  program  variable  or  control  variable  x  changes  value  during  a  phase. 
(Environment  variables  and  clock  variables  are  not  so  constrained.) 

(Yj>i  <  j  <  t\  :  fi(j)(x)  =  fi(ri)(x)) 

Third,  we  require  that  for  any  adjacent  phases 

•  •  • » *"<]»  fi),  ([**+1*  r»+l]»  /»+ 1  ))■•• 

2 There  are  two  exceptions.  Only  a  single  state  is  associated  with  the  very  beginning  of  the  trace;  and  for  finite 
traces,  only  a  single  state  is  associated  with  the  very  end  of  the  trace. 
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differences  between  states  /«(r{)  and  /«+i(ri+i)  are  the  result  of  executing  a  single  atomic  action. 
That  is,  the  state  change  can  be  attributed  to  traversing  an  edge  e  in  the  control  graph  where  (i)  the 
source  node  is  active,  (ii)  the  guard  evaluates  to  true  in  state  /,(r{),  and  (iii)  any  changed  program 
variables  in  state  /i+i(ri+1)  are  the  result  of  executing  the  multiple  assignment  labeling  edge  e. 
Our  control  graphs  are  for  2-process  programs,  so  without  loss  of  generality,  let  control  variables  t; 
and  w  be  true  in  phase  ([ri,r(],/i),  control  variables  v'  and  u>  be  true  in  phase  ([r,+i,  r!+i]>/*+i)’ 
and  edge  (v,v',g,x  :=  e)  be  in  the  control  graph.3  We  formalize  requirements  (i)  through  (iii)  by: 

•  Exactly  two  control  variables  are  true  in  each  of  states  /,(r()  and  /l+i(rt+j),  and  one  of  those 
control  variables  is  true  in  both  /«(r()  and  fi+iiu+i).  This  corresponds  to  the  restriction  that 
only  a  single  process  executes  a  single  atomic  action  between  adjacent  phases. 

•  Guard  g  is  true  in  state  /«(r^).  This  means  that  edge  (v,v\g,op)  can  be  traversed. 

•  The  value  of  every  program  variable  of  x  in  state  /,+i(rj+i)  is  equal  to  the  value  of  the 
corresponding  expression  in  e  in  state  /^(r();  the  value  of  no  other  program  variable  and  no 
environment  variables  changes  between  /,(r()  and  /»+i(rj+i).  Thus,  state  changes  are  due  to 
executing  assignment  x  :=  e. 

•  Clock  variable  fo*  equals  0  in  state  /<+i(rj+i);  clock  variable  and  jv  equals  0  in  state  /,(r,-). 
This  causes  the  clock  variables  to  have  their  intended  meanings. 

Finally,  all  clock  variables  change  value  within  a  phase  ((r»,  *■*],/«)  in  the  expected  way.  The 
value  of  a  clock  variable  c  at  time  t,  where  t  satisfies  r,-  <  t  <  rj,  is  given  by 

/<(*)(«)  =  /t(n)(c)  +  (t  -  r<). 

A  clock  variable  c  that  is  not  reset  in  state  /j(rj)  also  satisfies  /i(rj)(c)  =  fi(ri)(c)  +  (r(  —  r<). 

The  following  diagram  summarizes  how  the  starting  and  ending  states  of  adjacent  phases  in  a 
trace  are  related.  A  dashed  arrow  indicates  changes  to  environment  and  clock  variables;  a  solid 
arrow  denotes  changes  to  program  variables,  control  variables,  and  clock  variables  that  occur  by 
traversing  a  control  graph  edge.  The  trace  begins  at  state  /i(0)  and  the  state  changes  continuously 
according  to  the  function  /j,  until  time  r[.  At  time  r£,  an  instantaneous  state  change  occurs 
corresponding  to  execution  of  some  atomic  action.  This  causes  the  state  to  change  from  to 

/a(r2),  based  on  the  assignment  labeling  the  edge  of  the  control  graph  that  is  traversed  and  the 
resetting  of  certain  clock  variables. 


/i(0) . **  /i  (rl ) 

I 

A(r2)  - **  h(r7) 

\ 

h{ra 

3If  x  and  1  are  empty,  then  the  effect  of  execution  is  the  same  as  skip. 
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4  Properties 

We  now  introduce  a  language  for  expressing  properties.  We  restrict  consideration  to  safety  prop¬ 
erties  [15],  properties  that  assert  some  “bad  thing”  does  not  happen  during  execution.  Informally, 
formula  Init  =>  □/  defines  the  property  containing  all  traces  r  such  that  (i)  Init  does  not  hold 
initially  on  r  or  (ii)  /  holds  throughout  r.  Thus,  I  implies  that  the  ubad  thing”  being  prescribed 
by  the  safety  property  has  not  happened. 

In  formula  Init  =»  □/,  we  call  Init  and  I  assertions  and  assume  that  they  are  defined  by  the 
grammar  below.  There,  we  assume  x  is  a  program  variable,  X  is  an  environment  variable,  and  v 
is  a  control  variable.  We  also  assume  a  set  C  of  real  constants.  Finally,  opTti  denotes  a  relational 
operator  and  oparith  arithmetic  operator. 

A  ::  T  oprei  V  |  -vi  |  A  A  A!  |  (Vx.A  :  A') 

T  ::  C  |  Var  |  £(  Var)  j  T  oparith  V  |  T(T'\  \  ff  V  (4) 

Var  ::  x  |  X  |  «  |  I  i®  I  non? 

For  any  variable  a,  term  (a)  is  the  first  derivative  of  a  with  respect  to  time.  The  past  term 
T{T>\  equals  the  value  of  T  at  the  (past)  state  existing  V  units  ago.  And,  fj  T"  is  the  value  of 
the  definite  integral  of  term  T "  between  T  and  V . 

We  formalize  the  value  Mt(T)  of  a  term  T  in  a  finite  trace  r  inductively. 

MT(C)(t)  = 

Mt{  Var)(r)  = 

MT($,(V«r))(r)  = 

Mt(ToP.mT‘)(t) 

A<T(T(rj)(r)  = 

JHT(jfT")(r)  = 

The  value  Ma{A)  of  an  assertion  A  in  finite  trace  r  is  a  Boolean  function  defined  in  the  usual  way 
using  Mt- 

An  assertion  A  is  defined  to  be  valid  iff  for  every  finite  trace  r,  MA(A)(t)  =  true.  We  assume 
a  deductive  system  is  available  for  proving  validity  of  assertions. 

Finally,  we  formalize  the  set  of  traces  in  [[/nit  =>  □/]].  It  is  just  those  finite  and  infinite  traces 
r  for  which  MA{Init)(T.o)  =  false  or,  for  all  j,  MA(I){r..j)  =  true: 

r  €  [[Init  =>•  □/]] :  A4^(/nif)(r..0)  =  false  or 

(V;-0  <  j  <  |r| :  MA(I)(T.i)  =  true )  W 

5  Verifying  Hybrid  Systems 

When  verifying  a  hybrid  system,  we  are  interested  in  proving  that  executions  of  a  program  P 
satisfy  [[/nil  =>  □/]]  if  environment  variables  change  values  according  to  some  given  constraints 
(presumably  dictated  by  scientific  laws).  In  the  parlance  of  Section  2,  this  is  an  instance  of  proving 
that  P  satisfies  [[/nit  =>  □/]]  under  an  environment  £,  where  £  is  the  property  asserting  that 
environment  variables  only  change  values  according  to  the  given  constraints. 


C 

/»(*«)(  Far),  where  ([r,-,  r[],  fi)  is  the  last  phase  in  r 
Um^,^MT(  v‘r><T>-^(  v«r)(T  ,h— ar) 

=  MT{T)(T)oparithMT{T')(T) 

Im^  MTl.T")(rA)dt 
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Define  the  hybrid-environment  property  OEnv,  for  Env  an  assertion,  to  be  the  set  of  all  finite 
and  infinite  traces  where  Env  holds  throughout: 

r  €  [(□£n»]] :  (Vj.O  <  j  <  \t\  :  Mjk(Env)(r,.j)  =  true)  (7) 

Hybrid-system  verification  is  thus  equivalent  to  establishing  (P,  □  Env,  Init  =>  □/)  €  ESat.  Accord¬ 
ing  to  (2),  it  suffices  to  prove  [[/*]]  C  ([[/nit  =>  □/]]  U  [[DFriu]]).  We  accomplish  this  by  introducing 
another  property  [[W]],  called  a  hybrid  proof  outline ,  satisfying: 

m  c  m  (8) 

[[W]]C([[/„it=>D/]]UpS]])  (9) 

A  hybrid  proof  outline,  like  an  ordinary  proof  outline,  associates  assertions  with  control  points. 
In  particular,  a  hybrid  proof  outline  associates  an  assertion  with  each  node  in  a  control  graph. 
Assertions  are  of  a  restricted  form  so  they  cannot  be  invalidated  by  changes  to  environment  variables 
(which  might  occur  while  a  given  node  of  a  control  graph  remains  active). 

Rl:  Clock  variables  c  and  environment  variables  X  appear  only  in  past  terms  having  the  form 
X(c\.  Such  terms  do  not  change  value  during  a  phase,  even  as  clock  variables  advance  and 
the  environment  variables  are  updated. 

R2:  Terms  using  derivatives  are  not  permitted. 

Formally,  a  hybrid  proof  outline  is  a  triple  ft  =  (CGp,  7,  Env)  where  CGp  is  a  control  graph 
for  a  program  P,  7  maps  each  node  v  among  the  nodes  V  of  CGp  to  am  assertion  7„  satisfying  Rl 
and  R2,  and  mPnv  is  a  hybrid-environment  property.  The  assertion 

hi-  /\v*lv  (10) 

vev 

is  called  the  invariant  of  ft.  Property  [[7/]]  is  defined  to  be  the  set  of  all  finite  and  infinite  traces 
r  snch  that  (i)  r  does  not  satisfy  hybrid-environment  property  UEnv  or  (ii)  r  €  [[/■*  =>  □/«]]. 

For  an  assertion  A,  we  write  A[x  :=  e]  to  denote  the  textual  substitution  of  every  free  occurrence 
of  x  in  A  by  e.  The  following  theorems  give  conditions  for  verifying  (8)  and  (9)  above,  and  therefore 
they  give  a  method  for  establishing  [[/*]]  C  ([[/nit  =►  □/]]  U  [[OPnv]]). 

Theorem  1  Given  a  hybrid  proof  outline  ft  =  ((V,E,Vmtry,Eexi*),l,Env)  for  program  P,  then 
[[P]]  C  [[W]]  if  the  following  conditions  hold: 

•  For  every  (v,u,g,op)  €  E: 

( Env  A  v  A  7v  A  9A  iv  =  0)  =»  (11  A  7«)[op,  tu  :=  0,  v  :=  false ,  u  :=  true] 

is  valid. 

•  For  every  (v,  11,  g,  op)  €  E  and  every  w  €  V  such  that  v  and  w  are  nodes  of  different  processes: 

(Env  A»A7vAjA«;A  7u,A  jv  =  0)  =»  (tv  A  7u»)[op,  |u  :=  0,  v  :=  false,  u  :=  true] 
is  valid. 

Theorem  2  Given  a  hybrid  proof  outline  ft  =  ((V,E,  VmtTy,  Pe*»«),7,£nv),  if 

(Env  A  Init )  In  and  (Env  A  In)  =>  I 
are  valid,  then  [[W]]  C  ([[Init  =»  O/j]  U  [[n£Viv]]). 

The  proofs  of  both  theorems  are  in  Appendix  B. 


6  Example 

To  illustrate  the  approach,  we  return  to  the  control  program  in  Figure  1.  Sub-program  Si  reads 
the  water  level  (  WL)  in  a  tank.  If  the  level  is  too  low — less  than  or  equal  to  50 — then  a  pump 
is  activated,  causing  water  to  be  added,  until  the  level  reaches  95.  Sub-program  S3  monitors  a 
control  button.  When  the  button  is  pressed,  S3  toggles  the  valve  state.  The  two  components  for 
the  control  graph  of  this  program  appear  in  Figures  2  and  3. 

A  hybrid-environment  property  OEnv  for  this  system  asserts  that  changes  to  the  water  level 
are  based  on  the  pump  rate  and  valve  state.  We  assume  a  pump  with  throughput  0.5  l /sec  and  a 
valve  that  passes  0.25  if  sec.  When  the  valve  is  closed  and  the  pump  is  off  the  water-level  does  not 
change: 

(pa  =  off  A  vs  =  close )  =>■  WL)  =  0 

When  the  valve  is  open  and  the  pump  is  on,  the  water-level  increases  at  the  rate  of  0.25  l/sec, 
reflecting  the  relative  capacities  of  the  valve  and  pump: 

(ps  =  on  A  vs  =  open)  =>  WL)  =  0.25 

dt 

When  the  valve  is  open  but  the  the  pump  is  off,  the  water-level  decreases  at  the  rate  -0.25  l/sec. 

(ps  —  off  A  vs  =  open)  =>  ^-(  WL)  =  —0.25 

at 
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Finally,  when  the  valve  is  dosed  and  the  pump  is  on,  the  water-level  increases  at  the  rate  of  0.5 
tj  sec. 

(ps  —  on  At)«  =  close)  =>  — (  WL)  =  0.5 

at 

The  water  level  changes  over  time.  This  is  reflected  by  the  following  assertion,  which  states 
that  while  any  control  variable  u  holds,  the  water-level  equals  whatever  it  was  when  u  first  became 
true  plus  the  change  to  the  water-levd  since  that  time: 


(rnow  W  \ 

«=->*'£=  »Z<T«)+  I  3-(WX)) 


We  assume  that  execution  of  each  program  step  takes  at  least  0.5  units  of  time  and  at  mo6t  1 
unit  of  time: 

A  (“  =>  (t«  <  1))  A((|u  =  0)  =>  (Ttt  >  0.5)) 

,UJD ,...««  } 

Notice  that  real-time  execution  bounds  are  defined  using  an  assertion  about  the  environment.  This 
seems  natural,  since  there  is  nothing  intrinsic  about  the  program  text  that  supplies  such  bounds. 
Rather,  the  bounds  are  an  artifact  of  the  particular  processor  executing  the  program.  Moreover, 
assodating  the  bounds  with  the  environment  makes  it  possible  to  use  our  verification  framework 
for  different  real-time  behaviors. 

The  property  that  we  wish  to  establish  is  that  our  control  program  ensures  that  the  water-level 
remains  between  48  and  98.  We  formalize  this  property  as  Inti  =>  □/,  where: 


Init :  ps  ss  off  A  vs  as  close  A  wo  A  two  A  -> PRESSED  A  WL{ fwoj  =  90 
/  :  48  <  WL  <  98 

To  prove  that  this  property  holds,  we  construct  a  hybrid  proof  outline  W,  with  the  following 
mapping  7  that  assigns  an  assertion  to  every  node  in  the  control  graph.  Let  0  denote  the  xor  logic 
operation. 

7 tm  :(«o  ©  ...  0  ©e)  A  (two  ©  ...  0  twe)  for  i  as  0..6 

:(w s  =  open  V  vs  =  close) A 
(ps  =  on  V  ps  =  off) A 
ps  —  on  =>•  48.5  <  WI{tt*)$  <  96A 
ps  =  off  =►  49.5  <  WX(|wo$  <  98 

7„,  :(vs  as  open  V  vs  =  close) A 
(ps  =  onV  ps  =  off) A 
ps  =  on  =►  48.75  <  <  96.5A 

ps  =  off  a>  49.25  <  WL{ Twjfl  <  98A 
ti  =  ps  A  <2  =  WL{]v\\ 

7v_  :(vs  =  open  V  vs  =  close)  A  ps  =  off  A 
49  <  WL( Twafl  <  50 

7~  :(ws  =s  open  V  vs  =  close)  A  ps  =  off  A 
48.75  <  WL{ tv3$  <  50 

7v,  :(vs  =  open  Vm  =  close)  Aps  =  on  A 
95.25  <  WL( TM  <  97 
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7 vs  :(t>3  =  open  V  vs  =  close)  A  ps  =  on  A 
95.5  <  WLftusfl  <  97.5 

7«*  :(vs  =  open  V  vs  =  close) A 
(ps  =  on  V  ps  =  ojf)A 
ps  =  on  =>  49  <  wi/{t»sfl  <  95.5 
ps  =  Oj(f  =>  49.75  <  <  96.5 


According  to  Theorems  1  and  2,  we  must  then  check  the  set  of  verification  conditions  listed  in 
Appendix  C. 

7  Discussion 

Our  work  is  perhaps  closest  in  spirit  to  the  various  approaches  for  reasoning  about  open  systems.  An 
open  system  is  one  that  interacts  with  its  environment  through  shared  memory  or  communication. 
The  execution  of  such  a  system  is  commonly  modeled  as  an  interleaving  of  steps  by  the  system  and 
steps  by  the  environment.  Since  an  open  system  is  not  expected  to  function  properly  in  an  arbitrary 
environment,  its  specification  typically  will  contain  explicit  assumptions  about  the  environment. 
Such  specifications  are  called  assume-guarantee  specifications,  because  they  guarantee  behavior 
when  the  environment  satisfies  some  assumptions.  Logics  for  verifying  safety  properties  of  assume- 
guarantee  specifications  are  discussed  in  [9, 14,  21];  liveness  properties  are  treated  in  [1,  3,  23];  and 
model-checking  techniques  based  on  assume- guarantee  specifications  are  introduced  in  [6, 11]. 

Our  approach  differs  from  this  open  systems  work  both  in  the  role  played  by  the  environment 
and  in  how  state  changes  are  made  by  the  environment.  We  use  the  environment  to  represent 
aspects  of  the  computation  model  and  the  scientific  laws  governing  the  behavior  of  environment 
variables — not  as  an  abstraction  of  the  behaviors  for  other  agents  that  will  run  concurrently  with  the 
system.  This  generalizes  what  is  advocated  in  [8]  for  reasoning  about  fair  computations  in  temporal 
logic.  Second,  in  our  approach,  every  state  change  obeys  constraints  defined  by  the  environment, 
while  in  the  open  systems  view  only  state  changes  that  are  attributed  to  the  environment  must 
obey  those  constraints. 

Interest  in  verification  of  hybrid  systems  is  an  outgrowth  of  work  in  verifying  real-time  bounds 
for  concurrent  programs.  A  rather  substantial  literature  exists  on  the  subject;  see  [7]  for  a  collection 
of  surveys.  The  problem  of  reasoning  about  arbitrary  continuous  valued  state  components  was  first 
discussed  in  [24],  in  connection  with  process  control  program  for  railroad  control.  That  work  was 
ultimately  published  in  [20]. 

Our  underlying  semantic  model — traces — is  sHwflar  to  the  hybrid  traces  of  [18].  A  hybrid  trace 
consists  of  continuous  and  discrete  moments.  A  continuous  moment  is  mapped  to  a  single  state,  and 
a  discrete  moment  may  be  mapped  to  several  states.  With  our  notion  of  traces,  every  intermediate 
discrete  moment  is  mapped  to  exactly  two  states. 

Our  computation  model — control  graphs  and  hybrid-environment  properties — share  features 
with  phase  transition  systems  [18,  12],  hybrid  statecharts  [19],  and  hybrid  automata  [2].  Our 
computation  model  differs  in  its  separation  of  program  execution  from  changes  to  the  environment. 
The  control  graph  models  program  execution  and  the  hybrid-environment  property  models  state 
changes  to  the  continuous- valued  variables.  One  advantage  of  this  separation  is  that  changes  to 
the  computation  model  and  to  the  physical  laws  can  be  easily  accommodated.  A  second  advantage 
is  that  assertions  associated  with  control  points  in  a  program  (i.e.,  nodes  in  the  control  graph)  can 
be  simpler  because  they  need  not  explicitly  mention  environment  state  components. 
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Our  specification  language  contains  constructs  for  derivatives  and  integrals.  Such  constructs  also 
appear  in  the  specification  languages  of  [4, 12, 17,  5,  22].  Our  verification  methodology  extends  the 
Hoare-logic  methodology  of  [16]  to  hybrid  system.  Deductive- systems  for  proving  safety  properties 
of  hybrid  system  are  also  presented  in  [19,  13].  Our  work  differs  mainly  in  its  independence  from 
a  particular  computation  model. 
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A  Constructing  a  Control  Graph 

The  control  graph  CGs  that  corresponds  to  a  sub-program  5  is  defined  inductively,  as  follows: 

•  For  S  a  skip:  Define  V  =  {wq},  Ventr»  =  {vo},  E  =  {eo}  where  eo  =  (vo,?,  true, skip),  and 
Eexit  =  {eo}- 
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•  For  S  an  assignment  *  :=  e(y):4  Define  V  =  {«o,t>i},  Kntry  =  {«o},  and  £  =  {«o»ei}  where 
«o  =  (OB,»i,<rae,?  :=  y),  ej  =  (vt,1,true,x  :=  e(t)),  and  E^t  =  {«i>- 

e  For  S  a  statement  composition  Si;  S2:  Let  ( V1 ,  £* ,  V^try ,  E^ )  be  the  control  graph  for  Si 
and  let  (V2,  E2,  V2^^  E2^)  be  the  control  graph  for  S2.  Define  V  =  V1  UV2,  Ventry  =  V^try, 
Eegit  —  and 

E  =  E1UE2  -  ElxH  U  {(»,«',  y,op)|  3(v,  1,g,op)  €  £i*»t  and  a'  €  V*  *„} 


e  For  S  an  iteration  do  G\  — ►  S1QG2  — »  S2  od:5  Let  y  be  the  list  of  variables  mentioned  by  G\ 
and  Gi.  Let  (V1,^1,  V^.F^)  b®  the  control  graph  for  Si  and  let  (V2,E2,V2itry,E2git) 
be  the  control  graph  for  S2-  Define  V  =  V2  U  V2  U  {ao,oi},  Veno-y  =  {ao}, 

{(«0,»i,trt*e,t  :=  5)}U 

{ a, , a , <?i [t /y] , skip)  |  a  €  KL„}  U  {ai,»,G2[t/y],akip)  |  a  e  KU,}U 
{(u,,?oGi[t/ffl  A  -«G2[i/y],skip)}U 
{(a,ao,y,pp)|  3(a,?,y,op)  6  F^t  U 


and  Ecxit  =  {(vo,?,-.Gi(t/y]  A  -’G2[t/y],skip)} 

e  For  S  a  parallel  composition  Si  ||  S2:  Let  {Vl,El,  , F^ril)  b®  th«  control  graph  for  Si 
and  let  (V2,E2,  I^j,try,  E2^)  be  the  control  graph  for  S2.  Define  V  =  V1  U  V2,  Ventrv  = 
VLtry  U  V^lrv,  £*«<  =  E^t  U  F^t,  and  E  =  JE>  U  £2. 

B  Soundness  Proofs 

Lemma  1  Let  A  be  an  assertion  satisfying  R1  and  R2,  and  let  r  be  a  finite  trace.  If  t'  is  a  finite 
trace,  r  is  a  prefix  of  t#,  and 

(Vj.|r|  <  j  <  |t'|  :  r1 ^(x)  =  r(i)  for  every  program  variable  1,  and 
r* ’j(y)  =  r(y)  +  j  —  |t|  for  every  clock  variable  y), 

then  (Vj.|r|  <  j  <  M :  Ma{A)(t)  =  Mj^A)^)). 

Proof:  Since  A  satisfies  R.1  and  R2,  it  refers  only  to  program  variables  and  to  past  terms  of 
the  form  z(y\,  such  that  z  is  an  environment  variable  and  y  is  a  clock  variable.  Therefore,  the 
evaluations  of  the  terms  of  A  at  r  and  at  return  that  same  values. 

•v 

Theorem  1  Given  a  hybrid  proof  outline  Ji  =  ((V,FJ,V^,try,£erit)t7>£»”0  for  program  P,  then 
[[£*]]  C  [[7f]]  if  the  following  conditions  hold: 

•  For  every  (v,u,y,  op)  €  E: 

( Env  A  w  A  7„  A  yA  |t;  =  0)  =►  («  A  7u)[op,  t«  :=  0,  t;  :=  /alse,  u  :=  true] 


is  valid. 

4e(f)  denotes  that  expression  e  refers  to  variables  in  list  y. 

*To  simplify  the  presentation,  we  assume  only  two  alternatives. 
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•  For  every  (v,u,g,  op)  €  E  and  every  tv  £  V  such  that  v  and  w  are  nodes  of  different  processes: 

( Env  At?A7vApAti?A  7«,A  Je  =  0)  =»  (tt?  A  7*,)[op,  Tu  :=  0, v  :=  false,  u  :=  true] 
is  valid. 

Proof: 

1.  Let  r  €  [[P]),  where  r  =  ([rj ,  r^],  /a ),  ((r2,  r^],  /2), . . . 

2.  According  to  definition  of  [[?/]]  we  need  to  prove  that  either,  (i)  r  £  [[□£nv]],  or  (ii) 
Ma(Ih){t. o)  =  false,  or  (iii)  (Vj.O  <  j  <  |r|  :  Ma(I-h)(t..3)  =  true).  It  therefore  suf¬ 
fices  to  prove  that  if  (i)  and  (ii)  do  not  hold  then  (iii)  holds. 

3.  Assume  (i)  and  (ii)  of  2  do  not  hold,  so  t  €  [[□Fnc]]  and  Ma(Ih)(t..o)  =  true. 

4.  By  induction  on  the  number  i  of  the  phases  in  r,  we  next  prove: 

(Vj.  0  <  j  <  |r| :  AU(/w)(r.j)  =  true) 

Basis:  i  =  1.  According  to  3  we  have  that  Ma(^h)(t.jo)  =  true.  According  to  1  and  Lemma 
1  we  conclude  (Vj.O  <  j  <r\  :  Ma(Ih)(t..))  =  true). 

Step:  Assume  (Vj.O  <j<  r|_j  :  Ma(Ih)(t..i)  =  true)  holds  for  *  >  1.  We  prove: 

(Vj.ti  <  j  <  r'  :  MA(In)(r.j)  =  true) 

(a)  Ma{Ehv  A  In)(T__r'  =  true,  by  the  step  assumption  and  3. 

(b)  Without  lose  of  generality,  assume  (®,-_i,tp,_i)  ^5  («•,«;<)  such  that  t?,_i  /  c*,  tr,_j  = 
Wi,  and  and  tn,_i  are  true  in  r  •  .  According  to  1,  4(a),  and  the  definition  of  In- 

Ma(Euv  A  »i_ i  A  t»i_i  A  7v(_i  A  7 «*_,  A  g*  K-i  =  0)(r  r»^)  =  true 

(c)  Let  r*  be  obtained  by  extending  r  r»  ^  with  the  single  phase  ([r<,  r<],  /<).  Then,  according 
to  the  hypotheses  of  the  theorem  and  4(b) 

MA(vi  A  te<  A  7*  A  7^  )(r*)  =  true 

(d)  Let  j  be  such  that  r,-  <j<  r'.  Then  since  r  €  [[P]],  according  to  1  and  due  to  Lemma 
1: 

Ma{v*  A  Wi  A  7vj  A  7wi)(rm)  =  Ma(v{  A  m,  A  7*  A  7»i )(’*..>) 

(e)  According  to  4(c),  4(d)  and  definition  (10)  of  In,  Ma(Ih)(t..j)  =  true. 

Theorem  2  Given  a  hybrid  proof  outline  H  —  ((V',P,V^ntr*,Pe*»t)»7>£m0>  ^ 

(Env  A  Init)  =>  In  and  (Env  A  In)  =>  I 
are  valid,  then  ([H]]  C  ([[/nit  =>  □/]]  U  [[□■E’nt?]]). 

Proof: 
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1.  Let  r  €  [[ft]]. 

2.  According  to  definition  of  [[ft]],  either: 


(a)  r  €  [[□£n©]].  In  this  case,  r  €  ([[/nit  =>  □/]]  U  [[D£n©]]). 

(b)  r  €  [[D£n©]]  and  MA(In)(T.ja)  =  false.  In  this  case,  since  (£nw  A  /nit)  =>  In  we 
know  M^(Env  A  /nit)(r„o)  =  /aise.  However,  since  .M.4(£n©)(r..o)  =  true  we  get 
Mji(Init)(T'0)  =s  false.  Therefore  according  to  definition  (6),  r  €  [[/nit  =>  □/]]  and 
thus  r  €  ([[/nit  =>  □/]]  U  [[0£n©]]). 

(c)  r  €  [[□£©©]]  and  (VjJ 0  <  j  <  |t|  :  Mj((Env  A  /«)(r.j)  =  true).  In  this  case,  since 
by  hypothesis  ( Env  A  In)  =>  I  we  get  (Vj.O  <  j  <  |r|  :  Mjj(I){r..j)  =  true).  Thus, 
r  €  [[/nit  =*  □/]]  and  this  implies  r  €  ([[/nit  =►  □/]]  U  [[□£«©]]). 

C  The  verification  conditions 

The  following  conditions  must  be  proved  valid  in  ordered  to  complete  the  verification.  To  use 
Theorem  2,  we  must  prove: 

•  (Env  A  Init )  =>  In 

•  ( Env  A  In)  =»  I 

For  Theorem  l,  we  must  prove: 

•  (Env  A  ©□  A 7mA  j«o  =  0)  =>■  (©i  A  7«)[ti,t2  :=  ps ,  WL,\v\  :=  0,©o  :=  false, vi  :=  true] 

•t.i-  • 

•  (Env  A  ©i  A  7^  Atj  =  o#  At^<^ft{t7  =  0)  (©2A7,*)[T©2  :=  0,©i  :=  false,  v 2  :=  true] 

•  ( Env  A  ®i  A  7^  A  ti  =  on  A  tj  >  95A  i©i  =  0)  =>  (©4  A  7v«)[t»4  ■—  0,  ©i  :=  false,  ©4  :=  true] 

•  ( Env  A  ©1  A  7„,  A  (i(ti  =  off  At]  <  50)  A  -»(tj  =  on  A  tj  >  95))A  |©i  =  0)  =>  (vg  A  7„*)[Ttfc  := 
0,  ©j  :=  false,  ©g  :=  true] 

•  ( Env  A  ©2  A  7„j A  I ©2  =  0)  ^  (©3  A  7i*)[T©3  :=  0,©2  :=  false,v 3  :=  true] 

•  (£n©  A  ©4  A  7«,  A  I©4  =  0)  =»  (©5  A  7v5)[t©s  :=  0,©4  :=  false,  ©5  :=  true] 

•  (£n©  A  ©b  A  7„A  1©6  =  0)  =>  (©0  A  7m)[T«o  :=  0,©e  :=  false, ©0  :=  true] 

•  (Env  A  ©3  A7*,A  i©3  =  0)  =>  (©p  A  7^)[ps  :=  on,f©o  :=  0,©3  :=  false,  ©0  :=  true] 

•  (Env  A  ©5  A  7,*  A  |©s  =  0)  =>■  (©0  A  7,*)[ps  •'=  o/f,  t«o  •'=  0,  ©5  :=  false,  ©5  :=  true] 

•  (EnvAwiAgA  |t©j  =  0)  =»  («?j)[op,  :=  0,©;,  :=  false,  Wj  :=  true]  for  every  (t»j,t Cj,g,op)  € 

E. 

•  (£n©  A  ©  A  7v  A  g  A  t©A  j©  =  0)  =>  (t©)[op,  |u  :=  0,©  :=  false, u  :=  true]  for  w  in  CGst  and 
(v,u,g,op)  in  CGsx- 

•  (Env  A  w  A  Ag  A  v  A  7,,  A  |u?  =  0)  =►  (v  A  7v)[©P,  t u  :=  0,  t©  :=  false,  u  :=  true]  for  ©  in  CGs^ 
and  (w,u,g,op)  in  CGs 2. 
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